The present invention is related to data networking and more particularly to protocols for distributing information among multiple parties.
Communication of packets across the internet typically involves the use of a specific transport protocol called TCP. TCP provides certain services to higher layer applications that are not inherently provided by IP itself. For example, TCP guarantees message delivery, guarantees that packets will be transferred to the receiver application in the order they are transmitted, provides flow control to prevent overflow of receiver buffers, and throttles packet transmissions when network traffic conditions would lead to packet loss.
The TCP protocol assumes a single pair of nodes, one a transmitter and one a receiver. The transmitter and receiver may be multiple hops away from one another and packets traveling as a part of the same TCP session need not always traverse the same paths. To facilitate guaranteed message delivery, the transmitter maintains a cache of previously transmitted packets to allow for necessary retranmissions.
TCP is the “work horse” of the internet, carrying traffic for mail applications, web applications, etc. However, applications with certain characteristics are not well-served by TCP. For example, consider a database update distribution application. It is desirable for a selected node to distribute database updates to a number of nodes including nodes that are not directly-connected. Guaranteed message delivery is required as is in-order delivery. It is also desirable to be able to add nodes to the session and have them receive all the information that has been transmitted since the session's beginning.
A specific example of this type of distributed database updating is the distribution of routing information updates using BGP (Border Gateway Protocol) from border routers at the edge of an autonomous system (AS) to routers within the AS. The protocol for distributing this information to the AS interior is referred to as internal BGP or IBGP. Interior nodes that speak the IBGP protocol must obtain routing updates from border routers. To address this requirement, current IBGP techniques form a full mesh of TCP connections between each border router with updates to share and each interior router. Some degree of reduction in the number of TCP connections can be obtained by using route reflectors or confederations as specified by the BGP-4 protocol document. These simplifications cause problems such as routing loops and the number of TCP connections may still be very large. The use of numerous TCP connections, however, creates other problems.
One important problem is that each border router must separately buffer each TCP connection separately for retransmission purposes. Each TCP connection buffers all data that is pending acknowledgement. TCP will maintain separate retransmission buffers even though identical data is being sent to all receivers. Each TCP connection will also require extra CPU processing and other system resource overhead. This is a highly inefficient and cumbersome use of local high-speed memory and processing resources.
There is also great waste of network bandwidth. Multiple TCP sessions will typically carry identical data on the same link on their way to different target interior nodes. Because of the bipartite nature of the TCP connections, intermediate nodes cannot simply extract desired data from the sessions they support and need their own sessions instead.
What is needed is a transport protocol suitable for distributing database updates to multiple receivers while making efficient use of memory, processing resources and network bandwidth